It seems that no matter how fast/powerful computer technology becomes, users will never be completely satisfied with the speed with which their requests are handled. When their need for immediate responsiveness is not met, users seek other, more responsive systems to fulfill their computing needs. Today many software products are capable of meeting users' functional needs. Performance (e.g., responsiveness, efficiency, etc.) of the otherwise similar software systems has become increasingly important as a distinguishing characteristic.
Recognizing the importance of responsiveness of servers/services to ensuring consumer satisfaction, substantial effort is directed during software development/testing to ensure that performance is optimized in a computer software system. One way to ensure superior performance is to utilize software program architectures/frameworks that provide proven superior performance (e.g., speed, efficiency, etc.). Another way to ensure performance requirements are satisfied is to identify and correct portions of a software system that are adversely affecting performance (e.g., system bottlenecks, excessive resource drains).
Performance information is used in a variety of ways by software/system developers over the lifetime of the software to identify and correct poorly performing software. During the initial development stages, performance measurements are used to detect and remedy design or implementation deficiencies. Later, performance measurements can be used to respond to user concerns—to determine whether the particular software system is responsible for the performance problem. In yet other cases, performance information can be used to compare performance between earlier and later versions of software.
As used herein, a “request” refers to a request by an entity (e.g., a client) for some task to be performed by another entity (e.g., a server). A request has a finite life time, and the state of a request on the server, or other entity that executes the request, is determined by past events that have previously occurred (“fired”) in the course of fulfilling/completing the request. An event, within the context of tracing request completion, reflects/indicates the traced request's current state. Event tracing comprises recording the event along with relevant state information. In a simplest case, the request comprises a single executed identifiable task referred to herein as a “transaction.” However, completion of a request can involve/include a series of subtasks or “transactions” to be executed to generate the results for the requesting entity/client. A transaction is delimited by a start and end. As will be further explained herein below, the transactions resulting from a request may be nested or executed in a sequential fashion.
Performance testing is carried out in a variety of ways. For example, in known software performance evaluation tools, counters tally completion of tasks by a particular program component within a test period. By submitting a stream of requests at a rate that saturates a program component under test, one can determine its processing bandwidth. However, such testing is unrealistic in a multi-thread/multiprocessing computing environment where other programs share execution resources with the program component. This shortcoming can be addressed, at least partially, by submitting a mix of requests that simulate a typical load. Of course, one must first determine what constitutes a typical load. Furthermore, a typical load for a software program will likely vary from user to user—as well as the computer system hardware environment within which the software is executed.
Another way in which to assess system performance involves measuring the actual time required to execute a request through event tracing. Event tracing provides a set of time stamped log entries marking particular points of a server's completion of a request. In a known request execution tracing tool, trace events are fired at specified points within program code executed by a thread while completing a transaction or a series of transactions associated with a request. The trace events are logged as a sequence of trace records that include an event name, type, thread ID, and timestamp. Commencement and completion of a transaction is marked/measured by a traced start event and end event. Trace records also mark changes of state and save instantaneous parameter values. By storing an event name, a thread identification, event type (start/end), and a time when the event name/type occurred, the amount of time to complete each single-threaded transaction or set of transaction can be calculated. Thereafter, performance of the software is evaluated in light of the times for completing requests—as indicated by the logged trace events.
In more complex cases, execution of a request is traced within a single thread across multiple nested transactions. For example, Event A commences in response to a request, a nested transaction marked by Event B begins in response to starting a called function within the same thread, Event B ends and the program code associated with Event A resumes processing until Event A ends. This sequence of operations performed by a single thread is reported as a set of four, time-stamped traced event entries in a trace log (one for the start/end of each Event) including a same thread ID for each event. From this data, performance evaluators determine the total time to complete Event A (from start to finish) inclusive and exclusive of the time for executing Event B. For example, if Event A start-stop equals 15 units of time and Event B start-stop equals 5 units of time, then Event A required 10 units of time exclusive of nested Event B.
These prior means for providing performance data are useful to analyzing single threaded transactions and analyzing the operation of a single component in isolation. However, their utility is limited in servers or other complex computing systems where a request is likely to take on many different identities throughout the course of its completion (involving potentially many transactions). In these environments, the request is submitted to an entry point and returns at a later time. However, measuring only the entry and exit points of server request transactions gives little information about the delays encountered while various components of/processes within the server complete the transaction.